顧客ごとの業務規程はバージョンと適用条件を持つ設定として管理する
共通の処理と顧客別の規程を分け、適用する顧客・業務・有効日・バージョンを記録する。金額や承認条件などの必須ルールは、モデルの出力に加えて実行側でも検証する。
用語
- 業務ポリシー
- 期限・承認段階・対象条件など、その顧客の業務判断を定める規程。
- スナップショット
- ある時点の設定値を固定した記録。内容の妥当性は別に検証する。
- 有効日
- その規程を業務に適用する日付。公開日や処理日と一致するとは限らない。
図と例
顧客と適用条件を確定 → 設定差分とバージョンを確認 → 境界・例外で検証 → 実行側でも条件を強制
仮定の例：返金可能期間が顧客Aは30日、顧客Bは14日。購入20日後の依頼では、同じモデルでも適用する設定で結果が変わる。実行側が顧客と規程のバージョンを照合し、A向けの指示文が混入してもBで期限外返金を実行しない。数字は独自の業務設定例。
実際のサービス・製品では
Azure App Configuration
Azure App Configurationは、選択した設定値を変更不可のスナップショットとして保持し、バージョン管理や段階的な公開に使える。顧客の業務規程を正しく定める機能として扱わず、適用条件と実行時の検証はアプリ側で設計する。
資料を読む
解説
顧客の業務責任者に変更の確認と公開の担当を決めてもらう。設定差分を境界日と例外の事例で評価し、モデルや共通処理を替えたときは、影響する顧客別設定の組み合わせも検証する。
業務ポリシーは返金期限や承認段階など業務上の判断条件を定めたもの。顧客別に指示文をコピーして直すだけでは、どの規程がいつ有効になったか、他の顧客へ混入していないかを追いにくい。共通の実行処理から、検証済みの顧客IDに対応する設定を読み、業務の適用日とバージョンを確定して記録する。スナップショットは設定の値を固定して比較に使えるが、内容の正しさや全サーバーへの同時反映を保証するものではない。処理途中でバージョンが変わる場合の扱いを決め、古い設定を固定していても、権限剥奪や緊急停止を回避させない。
トレードオフ
- 共通処理と宣言的な顧客別設定で扱う
- 得るもの：差分と適用バージョンを比較しやすい
- 払うもの：設定のスキーマ・検証・公開手順を保守する必要がある
- 差が大きい業務を明示的な別実装にする
- 得るもの：顧客固有の処理順や連携を表現できる
- 払うもの：共通の修正への追随と顧客別の検証対象が増える
さらに学ぶ
チェック
返金規程が顧客Aは30日、顧客Bは14日。顧客Bの購入20日後の返金にA向けの指示文が混入した。実行側に必要なのは？
- 顧客Bの適用規程とバージョンを検証し、期限外の実行を拒否する
- モデルの出力に従いAの30日を使う
- 指示文を長くするだけで検証を省く
解答と解説
顧客Bの適用規程とバージョンを検証し、期限外の実行を拒否する
業務の必須条件は顧客Bに対応する規程で検証する。指示文の混入を実行側の判断に持ち込まない。長い指示やモデルの出力だけでは、顧客に合った条件の強制にならない。