JSONataとAWS Step Functionsで目指すRuntimelessな世界

https://serverless.connpass.com/event/371637/

1. #serverlessjp ServerlessDays Tokyo 2026 JSONataとAWS Step Functionsで目指す Runtimelessな世界 株式会社シーズ Yuta Nakamura / よ〜ん
2. #serverlessjp お話しすること • Step Functions + JSONataの現在地 • Runtimelessで何が変わるのか • AI時代にRuntimeを持つ意味 • どこまでRuntimelessにするか 設計思想や判断を中心にお話しします。
3. #serverlessjp Step Functions + JSONataの現在地
4. Step Functions + JSONataの現在地 #serverlessjp AWS Step Functions • AWSサービスなどをオーケストレーションする、フルマネージド ワークフローサービス • 順序・分岐・並列実行・待機をステートマシンで定義 • Amazon States Language (以降 : ASL) で記述
5. Step Functions + JSONataの現在地 #serverlessjp Service Integration • SDK integrations ◦ 220↑ AWS services ◦ 10,000↑ API actions • Optimized integrations ◦ 最適化された統合 出典: AWS Step Functions Developer Guide — Learn how to get started with Step Functions https://docs.aws.amazon.com/step-functions/latest/dg/getting-started.html
6. Step Functions + JSONataの現在地 #serverlessjp JSONPath → JSONata 5つのI/Oフィールドを、Arguments / Output / Assignへ整理 AWS Step Functions Developer Guide : https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/transforming-data.html
7. Step Functions + JSONataの現在地 #serverlessjp JSONata • クエリ／変換言語 • データ変換・条件判定 をASL内に記述 AWS Step Functions Developer Guide : https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/transforming-data.html
8. #serverlessjp Step Functions + JSONataの現在地 条件判定、データ加工まで JSONataで可能 Input JSONata Output { "orders": [ { "status":"paid", "amount":1200 }, { "status":"cancelled", "amount":800 }, { "status":"paid", "amount":3000 } ] } {% ( $paid := $states.input.orders[ status = "paid" ]; { "paidCount": $count($paid), "totalAmount": $sum($paid.amount) } ) %} JSONata + Step Functionsによって 表現できる範囲は広がった { "paidCount": 2, "totalAmount": 4200 }
9. #serverlessjp Runtimelessで何が変わるのか
10. Runtimelessで何が変わるのか #serverlessjp Runtimeless ? Managed Runtimeではありません。 Runtimeのライフサイクルを意識せず任意の処理を実行できるよ うな状態を指す、造語。
11. #serverlessjp Runtimelessで何が変わるのか Lambdaを持つということ Runtime SDK / Packages Build / Deploy Test / Monitoring コード関係なく、 Lambdaを1つ持てば Runtime lifecycle を1つ持つ
12. Runtimelessで何が変わるのか コードの書き換えが不要でも、アップデートは発生する #serverlessjp
13. #serverlessjp Runtimelessで何が変わるのか Step Functions + JSONataへ AWS SDK Before EventBridge / API Gateway Lambda AWS Service Service Integration After EventBridge / API Gateway Step Functions AWS Service Lambdaのコードだけでなく Runtime lifecycleそのものを管理対象から外せる
14. Runtimelessで何が変わるのか Runtimeless Runtimeless ≠ Runtimeが存在しない Runtimeless = 不要な Runtime lifecycle を所有しない Serverlessと似た感じ #serverlessjp
15. #serverlessjp EOLなんて、 AIにやらせばいいじゃん その通り
16. #serverlessjp AI時代にRuntimeを持つ意味 ≒Runtimelessって意味ある？
17. Runtimelessで何が変わるのか AIでRuntime updateは自動化できる #serverlessjp
18. #serverlessjp AI時代に Runtimeを持つ意味 AIでRuntime updateは自動化できる Applying this type of transformation across multiple Lambda functions used to require manual code changes. With AWS Transform custom, you can automate the upgrade. 訳：このタイプの変換を複数のLambda関数に適用するには、手 作業でコードを変更する必要がありましたが、 AWS Transform customを使えば、自動化できます。 Upgrading Lambda function runtimes at scale with AWS Transform custom : https://aws.amazon.com/jp/blogs/compute/upgrading-lambda-function-runtimes-at-scale-with-aws-transform-custom/
19. AI時代に Runtimeを持つ意味 #serverlessjp Runtimeある方が AI Friendlyでは？ • ローカルで実行できる • 既存ライブラリ / 開発ツール / 情報が豊富 • ASLと比較しTS / PythonはAIの学習データに多量に含まれ る AIにとって重要なのはコードを書けることより 変更を検証できること
20. #serverlessjp どこまで Runtimelessにするか
21. どこまで Runtimelessにするか 観点 • • • • • • • コスト 実行特性 / レイテンシ 保守 / 可読性 変更しない or 継続的に育てる オーケストレーション or ビジネス / ドメインロジックか AIとの相性 → Runtimeある方がAI Friendly 1環境 or 複数環境 #serverlessjp
22. どこまで Runtimelessにするか 観点 • • • • 保守 / 可読性 オーケストレーション or ビジネス / ドメインロジック AIとの相性 → Runtimeある方がAI Friendly 1環境 or 複数環境 #serverlessjp
23. どこまで Runtimelessにするか Runtimeless ≠ Maintenanceless Runtimelessにしても、保守対象は残る • ステートマシンの定義 ◦ ASL / JSONata • 繋ぎ込みの部分など ◦ IAM / AWSのAPI仕様 • 運用 ◦ 監視 / インシデント対応 #serverlessjp
24. どこまで Runtimelessにするか Runtimeless ≠ Maintenanceless Runtimelessにしても、保守対象は残る • ステートマシンの定義 ◦ ASL / JSONata • 繋ぎ込みの部分など ◦ IAM / AWSのAPI仕様 • 運用 ◦ 監視 / Runtime特有のメンテナンスを減らす インシデント対応 #serverlessjp
25. どこまで Runtimelessにするか 継続的に育てるコードには Runtimeを残す • • • • ドメインロジック 継続的な機能追加 外部ライブラリを使う処理 AI Agentが継続的に変更するコード 保守対象であり、コードを育てるための インターフェースでもある #serverlessjp
26. どこまで Runtimelessにするか Lifecycleのコストはコード修正だけではない コードが変わらなくても • • • • Health Event アップデート計画 リリース調整 etc… は発生する #serverlessjp
27. どこまで Runtimelessにするか Lifecycleのコストはコード修正だけではない コードが変わらなくても • • • • Health Event アップデート計画 リリース調整 etc… は発生する AIでLifecycleは軽くできるが、それ以外の部分は残る #serverlessjp
28. どこまで Runtimelessにするか Lifecycleのコストはコード修正だけではない コードが変わらなくても • • • • Health Event アップデート計画 リリース調整 etc… は発生する 小さいLambda 1つでも AIでLifecycleは軽くできるが、それ以外の部分は残る 複数アカウントとなると話は別 #serverlessjp
29. どこまで Runtimelessにするか 判断軸は「書けるか」ではなく「継続的に育てるか」 コードとして育てる価値 × 変更頻度 × 表現の自然さ すなわち、オーナーシップ で、Runtimeを残す / 外すを判断する #serverlessjp
30. #serverlessjp どこまで Runtimelessにするか Runtimelessにする判断軸 大きい ↑ Runtimeless 併用 Glue / AWS API連携 / 定型運用 展開規模が大きいほど嬉しい グルーとロジックで分離させる ケースバイケース Runtime 処理速度や外部連携など Web API / ビジネス / ドメイン 展開規模 ↓ 小さい 育てない ← コード →育てる
31. #serverlessjp まとめ • • • • • Runtimeを外すかどうかは、実装方式ではなく Ownership設計の問題 ◦ Step Functionsで書けるかではなく ◦ Runtime lifecycleを誰が持つべきかで考える AIによって Runtimeを持つコストと価値が変わった ◦ 更新作業は軽くできる ▪ ローカル実行・Test・型などはAIが変更を検証するための強いインターフェースになる コード量と運用コストは比例しない ◦ 複数環境 / アカウントに展開すれば、EOL・判断・調整は増幅する Runtimelessは複雑性を消すのではなく、置き場所を変える 安定した部分と、育てる部分を分離 ◦ Orchestration / Glueはマネージド側へ ▪ 継続的に変わるドメイン / ビジネスロジックはRuntimeへ
32. #serverlessjp まとめ • • • • • Runtimeを外すかどうかは、実装方式ではなく Ownership設計の問題 ◦ Step Functionsで書けるかではなく ◦ Runtime lifecycleを誰が持つべきかで考える AIによって Runtimeを持つコストと価値が変わった ◦ 更新作業は軽くできる ▪ ローカル実行・Test・型などはAIが変更を検証するための強いインターフェースになる コード量と運用コストは比例しない ◦ 複数環境 / アカウントに展開すれば、EOL・判断・調整は増幅する Runtimelessは複雑性を消すのではなく、置き場所を変える 安定した部分と、育てる部分を分離 ◦ Orchestration / Glueはマネージド側へ ▪ 継続的に変わるドメイン / ビジネスロジックはRuntimeへ Runtimelessは目的ではない 必要な場所だけに、 Runtimeを残す
33. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ • 変更しやすさ • 処理を表現できる幅 開発時 • SFn側の制約 ◦ Streaming非対応 実行時
34. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ AIエージェントが再発見したサーバーレス / めもおきば https://x.com/nekoruri
35. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ https://github.com/sam-goodwin/functionless
36. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ import { StepFunction } from "@functionless/aws-stepfunctions"; import MyDatabase from "./table"; export default StepFunction(async (input: { todoId: string }) => { await StepFunction.waitSeconds(10); await MyDatabase.attributes.delete({ Key: { pk: { S: "todo", }, sk: { S: input.todoId, }, }, }); }); https://github.com/sam-goodwin/functionless
37. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ https://github.com/DevNamedZed/simplesteps
38. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ import { Steps, SimpleStepContext } from '@simplesteps/core/runtime'; import { Lambda } from '@simplesteps/core/runtime/services'; const helloFn = Lambda<{ name: string }, { greeting: string }>( 'arn:aws:lambda:us-east-1:123456789:function:Hello', ); export const helloWorld = Steps.createFunction( async (context: SimpleStepContext, input: { name: string }) => { const result = await helloFn.call({ name: input.name }); return { greeting: result.greeting }; }, ); https://github.com/DevNamedZed/simplesteps
39. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ https://github.com/mu7889yoon/stately.asl
40. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ import {DynamoDBClient,PutItemCommand,GetItemCommand,} from "@aws-sdk/client-dynamodb"; export async function handler( TableName: string, Key: Record<string, any>, Item: Record<string, any>, ) { const client = new DynamoDBClient({}); await client.send(new PutItemCommand({ TableName, Item })); const result = await client.send( new GetItemCommand({ TableName, Key }) ); return result; } https://github.com/mu7889yoon/stately.asl
41. #serverlessjp EX 自由と制約のグラデーションのどこを目指すか？ DSL TypeScript 開発時の自由は高く保てる (かもしれない )