データ更新後に集計が変わったら、元データの追加・削除・修正と、期間・filter・計算定義の変更を分けて調べます。更新前後の保存データを同じ条件で比較し、変化した行が合計差へどれだけ寄与したかを確認してください。AIには差の候補と説明表を作らせ、もっともらしい原因を推測で確定させないようにします。
ここでは集計差を調べる手順と架空の金額例を示します。実際のDB照会、レポート更新、データ修正を行った結果ではありません。比較用の保存データはアクセス権と保管方針に従って扱い、個人情報や本番データを新しい外部サービスへ無断でコピーしないでください。
目次
変わった数字と集計条件を固定する
対象の指標、対象期間、日付基準、タイムゾーン、通貨、単位、filter、閲覧者、集計定義の版を記録します。表示画面の値だけでなく、どのデータ更新を反映しているかを確認します。利用者の権限や行の表示条件が違う場合は、元データが同じでも比較対象が変わり得ます。
更新前の値が必要なら、当時のデータや結果が保存されているか確認します。現在のデータへ過去日付のfilterを掛けただけでは、後日修正された過去行を元へ戻せません。保存物がない場合は、前後の行単位の差を復元できると断定せず、確認可能なログや元システムの履歴の範囲を示します。
同じ定義で前後を再集計する
表は横にスクロールできます
| 比較対象 | 同じにするもの | 違っていれば残すもの |
|---|---|---|
| データ範囲 | 対象法人、期間、確定/未確定 | 追加source、遅延到着、削除 |
| 単位 | 通貨、税抜税込、数量単位 | 換算表と換算時点 |
| 計算 | 対象列、集計式、丸め | 新旧の式と定義変更 |
| 結合 | key、対応関係、結合方式 | 重複key、参照先追加 |
| 表示 | filter、閲覧権限、更新時点 | report側の条件差 |
最初に旧定義と同じ条件で更新前後を比較し、データ差を確認します。次に同じデータへ新旧の定義を適用し、定義差を確認します。データと定義を同時に変えた二つの総額だけから、「新規売上が増えた」と原因を一つに決めないでください。
安定したkeyで追加・削除・修正を分類する
行番号ではなく、同じ業務レコードへ戻れるIDを使います。明細単位なら親IDと明細IDなど、一意性を確認したkeyを選びます。欠損や重複がある場合は、比較を進める前に別一覧へ出します。名前や金額が近い行をAIに同一と推測させると、削除と追加が修正へ見えてしまいます。
SQLを使う環境では、両側にしかない行を残すFULL OUTER JOINが比較方法の一つです。PostgreSQLの結合説明(新しいタブで開く)でも、両側の不一致行を含める動作が示されています。使うDBの対応を確認し、結合後のfilterで不一致行を落としていないかも点検します。複数行が同じkeyへ一致すると組合せが増えるため、単に結合した結果を足す前に一意性を確認してください。
比較表はkey、旧値、新値、差、変更区分、元データ参照を持たせます。新側だけなら追加、旧側だけなら削除、両側にあり対象値が変われば修正です。ただし、取得漏れや権限差で見えなくなった行を業務上の削除と確定しません。データ取得の完了と対象範囲を確認してから区分を採用します。
架空の合計差を寄与へ分ける
旧合計が1,000、新合計が1,180の架空例を考えます。同じ期間・通貨・定義で、新規行が250、消えた行の旧値が100、既存行の修正差が30なら、差は250−100+30=180です。旧合計1,000へ180を足すと新合計1,180になります。これは計算例で、実際の売上増加を示すものではありません。
表は横にスクロールできます
| 寄与 | 架空の値 | 根拠として必要なもの |
|---|---|---|
| 追加行 | +250 | 新側だけにある対象IDと値 |
| 削除行 | -100 | 旧側だけの対象IDと旧値、取得範囲確認 |
| 既存行の修正 | +30 | 同じIDの新値−旧値 |
| 合計差 | +180 | 前後総額との差が一致すること |
この分解は加算可能な金額合計の例です。平均、割合、中央値、distinct件数へ同じ寄与式をそのまま使いません。平均なら合計と件数、割合なら分子と分母を分けて比較します。カテゴリの付替えは全体合計が同じでも区分別の数字を変えるため、移動元と移動先を対応付けます。
説明できない残差は未確認として残す
寄与を足しても総額差と合わない場合は、丸め、nullの扱い、重複結合、filter、時刻境界、未完の取得や更新時点を順に確認します。nullを無条件にゼロへ置き換えると、欠損と実額の差が見えなくなります。AIへは残差、根拠のある候補、次に確認する場所を返させ、数値が合う原因を創作させないでください。
修正が必要と分かった場合も、説明用データを直して元へ書き戻さず、担当者が正本と処理への影響を確認します。keyや計算条件を変えたら同じ保存データから再比較し、合計だけでなく追加・削除・修正の件数と代表行も確かめます。最後にデータ版、集計版、比較条件、寄与、残差、未確認を記録すれば、次回更新時も同じ問いから調べられます。
