データ変換ロジックをコードから追い出す技術 "Transform Rules"

データ変換ロジックをコードから分離する技術 "Transform Rules"

CSVやJSONファイルから統一した出力を定義できるデータ変換エンジンを作成したので、そのご紹介になります。

▼いきなりですがプレイグラウンドでお試しいただけます

▼ソースはこちら

▼ transform-rules リファレンス

本記事は一部生成AIによって生成されております。

私が経験した「開発の悩み」

外部APIやレガシーシステムと連携する機能を作っているとき、こんな経験がありました。

• 連携先のAPI仕様が変わり、フィールド名が user_name から userName に変わった。
• たったそれだけの修正なのに、アプリケーション全体のビルド・テスト・デプロイが必要になった。
• 仕様を確認したいのにドキュメントが古く、結局ソースコードを解読して変換ロジックを追う羽目になった。

コードの中に変換ロジック（マッピング）を埋め込むのは自然なことですが、システムが大きくなるにつれて、これが「変更への足かせ」になってしまっていました。

「変換ルール」を外に出すという発想

そこで思いついたのが、Transform Rules というアプローチです。
考え方はシンプルです。「何をどう変換するか（ロジック）」をコードから切り離し、YAMLファイルに任せるのです。

ルールエンジンである「Drools」から着想を得ており、YAMLルールにロジックを書いてしまおう！という思いつきです

この考えは非常にうまく機能しました。
次の3つの恩恵を受けられたからです。

1. デプロイ不要: ルールファイルを差し替えるだけ。アプリ本体はそのまま稼働し続けられた。
2. 仕様の透明化: YAMLファイルを見れば「どの項目がどう変換されるか」が一目瞭然。
3. 再利用性: 複数のマイクロサービスで、同じ変換ルールを共有できる。

具体例：バラバラな気象APIを統一する

具体的なシーンで見てみましょう。
「仕様の違う2つの天気予報API」からのレスポンスを、自社アプリで使いやすい統一フォーマットに変換します。

目標：この形（統一フォーマット）にしたい

{
  "city": "Tokyo",
  "temperature_celsius": 22.5,
  "description": "sunny"
}

例: サービス間のデータ差異を吸収

サービスのデータ形式	YAMLルール	Transform rules出力
# Service A [csv] city,temp_c,condition Tokyo,22.5,sunny	mappings: - target: "city" # 自社の項目名 source: "input.city" # 相手の項目名 type: string - target: "temperature_celsius" source: "input.temp_c" type: float - target: "condition" source: "input.condition"	{ "city": "Tokyo", "temperature_celsius": 22.5, "description": "sunny" }
# Service B [json] { 　"location": { "name": "Okinawa" }, 　"current": { 　"temperature": 80.6, // 華氏(°F)表記 　"weather": "clear sky" 　} }	mappings: - target: "city" source: "input.location.name" # ネストはドットで指定 - target: "temperature_celsius" expr: # 変換ロジックを定義 「°C = (°F - 32) × 5/9」 op: "*" args: - { op: "-", args: [{ ref: "input.current.temperature" }, 32] } - { op: "/", args: [ 5, 9 ] } type: float - target: "condition" source: "input.current.weather"	{ "city": "Okinawa", "temperature_celsius": 27.0, "description": "clear sky" }

Service Bでは、温度の単位も違います（華氏）。変換ロジックをYAMLルールで書けます。

ポイント
アプリケーション側は「統一フォーマットが来る」ことだけ知っていれば十分です。
「Service Bは華氏で値を返してくる」といった泥臭い知識は、すべてYAMLの中に封じ込めることができます。

Transform Rules ができること

Transform Rules は Rust製のライブラリですが、CLIツールやWebAssemblyとしても動作します。単なるマッピングだけでなく、実務で必要な機能が揃っています。

1. データの正規化・演算 (Expression)

Excelの数式のような感覚で、データ加工が可能です。

• 文字列操作: concat (結合), trim, lowercase など
• 数値計算: 四則演算
• 条件分岐: when を使った「もしステータスがactiveなら...」といったロジック
• ルックアップ: マスタデータ（配列）の中からIDで検索して名称を取得する

2. マスタデータとの結合 (Context Injection)

変換時、APIレスポンスだけでなく、外部から「マスタデータ」や「環境変数」を注入できます。

例：注文データにある customer_id を使って、注入された顧客マスタから customer_name を引く

  - target: "customerName"
    expr:
      op: "lookup_first"
      args:
        - { ref: "context.customers" } # 注入されたマスタ
        - "id"
        - { ref: "input.customer_id" } # 入力データ
        - "name"

これをYAMLだけで完結できるため、コード内で非効率なループ処理を書く必要がなくなります。

3. DTOコードの自動生成

「YAMLで定義するのはいいけど、アプリ側の型定義(クラス)を作るのが面倒」
そう感じる方も多いでしょう。

Transform Rulesは、ルールファイル（YAML）から以下の言語の型定義ファイルを自動生成できます。

• Rust (struct)
• TypeScript (interface)
• Go (struct)
• Python (dataclass)
• Java, Kotlin, Swift...

つまり、YAMLさえ更新すれば、対応するプログラムコードも自動で手に入るということです。

ユースケース

マルチテナント対応

A社とB社でデータの出力形式を少しだけ変えたい場合、コードは共通のまま、テナントごとのYAMLファイルを適用するだけで対応完了します。

まとめ

データ変換ロジックをアプリケーションコードから「分離する」ことで、システムはより柔軟になります。

	従来の方法（コード埋め込み）	Transform Rules
API仕様変更	コード修正＆再デプロイ	YAML修正のみ（即反映）
仕様の確認	コードを解読	YAMLを読むだけ
型の管理	手動で追従	自動生成

「たかがデータ変換」と思われがちですが、ここを疎結合にするだけで、開発体験（DX）は劇的に向上します。

冒頭にも記載しましたが、
ぜひ下記のプレイグラウンドでお試しいただければと思います。