ルールベース変換エンジン設計

規則をコードから追い出す

入力データを別の形へ変換する処理は、素直に書くと分岐の塊になります。

if row['種別'] == 'A':
    out['区分'] = '01'
elif row['種別'] == 'B' and row['金額'] > 10000:
    out['区分'] = '02'
# ... 200行続く

問題は「規則が変わるたびに開発者が要る」ことです。 業務側から「Cのときは03」と言われるたびに、修正・レビュー・リリースの一巡が必要になります。

ルールベース変換エンジンは、この規則をコードの外のデータとして持ちます。

| 条件(種別) | 条件(金額) | 出力(区分) |
|-----------|-----------|-----------|
| A         |           | 01        |
| B         | > 10000   | 02        |
| C         |           | 03        |

エンジンは「表を読んで、当てはまる行を探し、指定された出力を作る」だけです。規則が増えてもエンジンのコードは変わりません。

Excelを定義の置き場にする

規則の置き場は [[YAML]] や JSON でも構いませんが、業務担当者が編集するなら Excel が現実的です。

  • 業務側が既に使えて、追加の学習が要らない
  • 表形式が規則の構造(条件 → 出力)とそのまま一致する
  • 差分の確認やレビューは弱いが、規則の一覧性は高い

[[Excel自動生成]] が「プログラムから Excel を作る」方向なのに対し、こちらはExcel を入力として読む方向です。同じ Excel でも役割が逆になります。

判断の分かれ目

規則を外に出せば必ず良い、ではありません。

ルール化が効く効かない
規則が頻繁に変わるほぼ変わらない
業務側が規則を決める開発者が決める
規則が表で表せる(条件 → 出力)手続きや例外処理が絡む
件数が多い(数十〜)数個

規則が変わらないなら、コードに書いたほうが読みやすく速いです。手続き的な処理を無理にルール化すると、表の中に貧弱なプログラミング言語を作ることになります — 分岐やループを表現するための独自記法が増え、デバッグ手段が無い言語ができあがります。これがこの設計の最大の失敗形です。

設計で必ず要るもの

規則がデータになると、規則そのものが壊れうるという新しい問題が生まれます。

  • 規則の検証 — 読み込み時に形式を確認する。[[JSON Schema]] のような宣言で「必須列がある」「値が既定の集合に入る」を検査します。実行時に初めて壊れると、原因が入力データか規則か分かりません
  • 一致しなかったときの扱い — どの規則にも当てはまらない入力をどうするか(既定値・エラー・そのまま通す)を決めます。無言で欠落させないことが重要です
  • 複数一致したときの扱い — 上から最初に一致したものを使う、という規則を明示します。曖昧なままだと、規則を足した順で結果が変わります
  • どの規則が適用されたかを記録する — 結果だけでは検証できません。「行12に規則5が適用された」が残っていれば、業務側が自分で確認できます

運用で効くこと

  • 規則の版を管理する — 誰がいつ何を変えたかが追えないと、出力が変わった原因を特定できません。ファイルをリポジトリに置くのが最も簡単です
  • 規則を変えたら回帰を見る — 過去の入力と出力の組を残し、規則変更後に差分が出た件を確認します([[自動テスト]] の考え方をデータに適用します)
  • [[ドキュメンテーション]] は規則の書き方に対して書く — エンジンの内部より、業務側が読む「条件の書き方」の説明が価値を持ちます

関連技術とのつながり

  • [[Excel自動生成]] — Excel を出力する側。本記事は入力として読む逆方向
  • [[JSON Schema]] — 規則そのものの形式を検証する仕組み
  • [[データパイプライン・ETL]] — 変換処理を組み込む先の全体構造
  • [[YAML]] — 開発者が規則を管理する場合の記述形式
  • [[ドキュメンテーション]] — 業務側が規則を書けるかどうかが成否を決める
Q: 変換規則をコードの外へ出す最大の狙いはどれ?
- [ ] 実行速度を上げる
- [x] 規則の変更に開発者の修正・リリースを不要にする
- [ ] メモリ使用量を減らす
解説: 規則が増えてもエンジンのコードは変わらない構造にします。

Q: ルールベース化が向かないのはどれ?
- [ ] 規則が頻繁に変わる
- [ ] 業務側が規則を決める
- [x] 手続きや例外処理が絡み、表で表せない
解説: 無理にルール化すると、表の中に分岐やループの独自記法が増え、デバッグ手段の無い言語ができあがります。

Q: 規則がデータになったときに新たに必要となる仕組みはどれ?
- [x] 規則そのものの形式検証と、どの規則が適用されたかの記録
- [ ] 規則の暗号化
- [ ] 規則の圧縮
解説: 実行時に初めて壊れると、原因が入力データか規則か切り分けられません。適用履歴があれば業務側が自分で確認できます。