AWSは、柔軟なデータ変換ワークフローを構築するための仕様主導型コンポジションパターンを提示した。これにより、ワークフローの意図と処理ロジックを分離し、重複したパイプラインコードを削減し、検証とガバナンスを簡素化する。このアプローチでは、構造化された仕様を用いて再利用可能な処理ケイパビリティを動的に組み立て、AWS Lambda、AWS Step Functions、Amazon S3、Amazon OpenSearch Serviceに基づいたサーバーレス実装を採用した。
このパターンは、組織がデータセットやワークフローの派生パターンを追加するにつれて保守が困難になるデータパイプラインを対象としている。AWSは、スクリプトベースの実装では、オーケストレーション、変換、検証ロジックが混在していることが多く、新しいデータセットが導入されるとコードの変更や再デプロイが必要になると指摘。その結果生じるコードの重複は、特に規制の厳しい環境において、ワークフローの動作の追跡を困難にすることもある。
仕様主導型コンポジションは、ワークフローを3つの層に分ける。仕様を含むインテント層、仕様を検証してパイプラインを組み立てるコンポジション層、変換ステップを実行する処理層である。
/filters:no_upscale()/news/2026/08/aws-spec-driven-data-workflow/en/resources/1Screenshot%202026-08-16%20at%209.41.42%E2%80%AFPM-1786944921986.png)
3層の仕様駆動型コンポジションアーキテクチャ（出典：AWSブログ記事）
Rajat Shrivastav氏は、LinkedInでAWSによるこのパターンの説明について次のようにコメントした。
意図を宣言的な仕様として明文化することで、トレーサビリティ（追跡可能性）が後付けの要素ではなく、パイプラインの中核となることを保証します。
通常仕様は、JSONやYAMLで表され、ソースおよびターゲットのデータセット、フィールドのマッピング、変換を記述するが、それらの変換がどのように実装されるかは定義しない。コンポーザーは仕様を検証し、参照される機能を確認し、実行可能なワークフローを生成する。 機能レジストリは、識別子、入力および出力形式、呼び出しの詳細、権限、バージョンなど、再利用可能な変換関数のメタデータを管理する。
AWSの実装例では、ワークフロー仕様をAmazon S3に保存する。S3イベントがLambdaベースのコンポーザーを呼び出し、コンポーザーは仕様を検証し、Amazon OpenSearch Serviceへ機能メタデータを問い合わせる。その後コンポーザーはAWS Step Functionsのステートマシンを作成・起動し、個々のLambdaベースの機能プロセッサを呼び出す。プロセッサは、Amazon CloudWatch Logsにトレース情報を出力する。
/filters:no_upscale()/news/2026/08/aws-spec-driven-data-workflow/en/resources/1awsspecarch-1786944921986.jpeg)
仕様駆動型コンポジションのAWS実装（出典：AWSブログ記事）
また、このレジストリでは、説明、スキーマ、タグなどのメタデータを用いたケイパビリティの発見も可能だ。仕様では、作成者が特定の実装識別子を知る必要なく、意図によって再利用可能な変換を参照できる。AWSはまた、再現可能なワークフローの実行や、新機能の検証と承認を分離するために、バージョン管理された機能参照についても説明した。
このパターンでは、データ分類を仕様に組み込める。機密性の高いフィールドにはタグを付与でき、機能は機密性に対してどのような影響を与えるかを宣言する。コンポーザーはこの定義を用いて結果の分類を検証し、下流工程の利用者向けにマスキング用の成果物を生成できる。
AWSは、トレーサビリティや実行前の検証が重要である規制報告、マルチソース統合、および再利用可能なETLワークフローに向けて、このパターンを位置付けた。同社はまた、仕様主導型コンポジションは、単純な変換や少数のワークフローしかない環境では不必要な複雑さを招く可能性があり、ワークフローの多様化やガバナンス要件の増加に伴い、この手法の適用性がより高まると指摘した。