すべての変更を、記録する — 項目単位の差分履歴(監査ログ)の設計と活用

「いつ・誰が・どの項目を・どう変えたか」を差分で残す。監査・復旧、そしてAI操作の追跡までを支える土台。

WHYなぜ項目単位の差分なのか

基幹エンジンでは、受注・顧客・在庫といったデータが日々書き換わります。「最終状態」だけを保持すると、ある値がなぜその値になったのかを後から説明できません。そこで採るのが、変更を「項目単位の差分(変更前→変更後)」として残す設計です。レコード全体を丸ごとコピーするのではなく、実際に動いた項目だけを差分として抽出することで、履歴は軽く、かつ「何が変わったか」が一目で読み取れます。

この差分に、実行者・日時・処理セッションIDを添えれば、「いつ・誰が・どの項目を・どう変えたか」が一件のレコードに閉じます。これが監査ログの最小単位になります。

FLOW共通の更新経路で生成する

要は、履歴を「書き込みのついで」に作るのではなく、すべての書き込みが必ず通る共通経路の中で生成することが肝心です。個々の業務ロジックが履歴生成を各自で実装すると、書き漏れや形式のばらつきが必ず生じます。

• 更新要求を受け取ったら、更新前後の値を比較して変化した項目だけを抽出する。
• 抽出した差分に実行者・日時・処理セッションIDを付与し、履歴レコードを組み立てる。
• 永続ストアへ追記(append)する。既存の履歴は書き換えない(イミュータブル)。

KEY保存キーとマスキング

履歴レコードは、業務単位ID(受注IDなど)と時刻を組み合わせたキーで保存します。こうしておくと、同じ業務単位の変更が時系列で自然に並び、「この受注に何が起きたか」を時間軸で辿れます。個人情報などマスキング対象の項目は、差分の値そのものを伏せて記録する配慮も入れられます。変更があった事実と実行者は残しつつ、中身は保護する、という監査とプライバシーの両立です。

USE五つの活用

• 監査・内部統制:誰が何をいつ変えたかの証跡がそのまま残る。
• フォレンジック再構成:ある状態がどの操作で生じたかを操作単位で辿れる。
• ロールバックの根拠:変更前の値が残るため、戻す判断と実行の裏付けになる。
• AIエージェントの操作追跡:実行者にAIの識別子を入れれば、人と同じ精度で「どのAIが何を変えたか」を残せる。
• AI改善の学習・評価データ:「指示→変更→結果」の履歴は、エージェントの挙動評価や改善の素材になる。

{
  // 業務単位ID + 時刻 をキーに時系列で並ぶ
  "bizId": "ORDER-000000",
  "timestamp": "2026-07-03T09:15:22.481Z",
  "userId": "agent:vegas-bot-01",   // 人でもAIでも同じ枠に
  "sessionId": "sess-7f3a...c19",
  "rgstType": "upd",                 // add / upd / del
  "diffs": [
    { "field": "qty",   "before": 1,      "after": 3 },
    { "field": "status","before": "hold", "after": "ship" },
    { "field": "tel",   "before": "****",  "after": "****" }  // マスキング対象は値を伏せる
  ]
}

TRADEOFF増え続けるコストと引き換えに

追記型の履歴は、放っておけば無限に増えます。保持ポリシー(いつまで残すか、どこへアーカイブするか)、検索を支えるインデックス設計、そしてストレージコストの見積もりが前提として必要です。差分だけに絞る、マスキングで肥大化を抑える、といった工夫はここに効きます。一方で「どの時点も、どの操作単位でも再現できる」監査性は、事故対応やコンプライアンスの局面で明確な資産になります。増分のコストを払ってでも持つ価値がある、という判断が設計の分かれ目です。