申請・稟議・契約・経費精算などをシステム化するとき、
「承認済みというステータスだけ残せばよい」
「最終承認者だけ分かれば十分」
「現在の申請内容を保存しておけば問題ない」
と考えていないでしょうか。
日常業務だけであれば、
この申請は承認済み
と分かれば十分なケースもあります。
しかし、監査やトラブル調査では、
- 誰が申請したのか
- 誰が承認したのか
- いつ承認したのか
- どの内容に対して承認したのか
- 途中で差し戻しがあったのか
- 承認後に内容が変更されていないか
まで確認する必要が出てくることがあります。
そのため、承認フローをシステム化する場合は、承認履歴を監査証跡として後から追跡できる状態にしておくことが重要です。
例えば、
2026年7月30日 10:05
申請者：田中
申請金額：500,000円
2026年7月30日 13:20
課長：佐藤
処理：承認
2026年7月31日 09:15
部長：鈴木
処理：承認
という履歴が残っていれば、
誰がどの順番で承認したのか
を確認できます。
さらに監査証跡として利用するなら、
そのとき承認者が見ていた申請内容まで追跡できる設計
を検討する必要があります。
この記事では、承認履歴を監査証跡として残すために必要な情報、承認・差し戻し・代理承認の設計、申請内容の変更や改ざんをどう考えるかまで具体的に解説します。
承認履歴の監査証跡とは
監査証跡とは、システム上で行われた処理や判断を後から追跡するための記録です。
承認業務であれば、
- 申請
- 承認
- 差し戻し
- 再申請
- 却下
- 代理承認
- 申請取消
などの履歴を残します。
重要なのは、単純に、
「現在：承認済み」
と表示することではありません。
例えば、
申請
↓
課長承認
↓
部長から差し戻し
↓
申請者が修正
↓
再申請
↓
課長再承認
↓
部長承認
という流れだった場合、その一連の履歴を後から確認できることが重要です。
つまり監査証跡では、
現在の状態だけではなく、そこへ至るまでの過程を残すこと
がポイントになります。
「承認済み」だけでは監査証跡として不十分な理由
例えば、申請データに次の項目だけがあるとします。
ステータス：承認済み
承認者：鈴木
承認日：2026年7月31日
一見すると問題なさそうです。
しかし、この情報だけでは、
- 途中で誰が承認したのか
- 差し戻しがあったのか
- 申請内容が途中で変更されたのか
- 鈴木さんがどの金額を承認したのか
が分かりません。
例えば、
申請時：100万円
↓
承認
↓
後から200万円へ変更
できてしまう設計なら、
承認者が100万円を承認したのか、200万円を承認したのか
を判断できなくなります。
そのため、承認履歴を監査証跡として使う場合は、
承認という操作と、その時点の申請内容を結び付けて考えること
が重要です。
承認履歴に残したい基本項目
承認履歴では、最低限次の情報を検討します。
1．対象となる申請
どの申請に対する承認なのかを特定します。
例えば、
申請ID：APP-000125
など、一意に識別できるIDを持たせます。
タイトルだけでは同名の申請が存在する可能性があるため、内部IDなどで識別する方が確実です。
2．処理したユーザー
誰が操作したのかを記録します。
例えば、
ユーザーID：user0025
氏名：佐藤太郎
などです。
氏名は変更される可能性があるため、システム内部ではユーザーIDも保存します。
3．処理日時
いつ承認・差し戻しなどを行ったのか記録します。
例えば、
2026-07-30 13:20:15
という情報です。
複数システムを利用する場合は、タイムゾーンも統一して管理します。
4．処理内容
例えば、
- 申請
- 承認
- 差し戻し
- 却下
- 取消
- 再申請
などです。
単なるステータス変更ではなく、何の業務判断を行ったのか記録します。
5．承認ステップ
複数段階の承認では、
課長承認
部長承認
役員承認
など、どの段階の処理だったか分かるようにします。
6．コメント
承認・差し戻しの理由や補足コメントです。
特に差し戻しでは、
金額の根拠を追記してください
といった理由を残すことで、後から経緯を確認できます。
7．代理承認かどうか
本人ではなく代理者が承認した場合、その事実を残します。
例えば、
本来の承認者：佐藤
実際の承認者：鈴木
処理：代理承認
という情報です。
【例】承認履歴として残すデータ
例えば次のような履歴です。
| 日時 | 操作者 | 操作 | ステップ | コメント |
|---|---|---|---|---|
| 7/30 09:10 | 田中 | 申請 | 申請者 | 新規購入申請 |
| 7/30 11:25 | 佐藤 | 承認 | 課長 | 問題なし |
| 7/30 15:40 | 鈴木 | 差し戻し | 部長 | 見積書を追加してください |
| 7/31 09:05 | 田中 | 再申請 | 申請者 | 見積書追加 |
| 7/31 10:30 | 佐藤 | 承認 | 課長 | 再確認済み |
| 7/31 13:15 | 鈴木 | 承認 | 部長 | 承認 |
この履歴が残っていれば、
最終的に承認された
だけではなく、
途中で何が起こったのか
を確認できます。
承認時点の申請内容を残す
承認履歴設計で特に重要なのが、
何に対して承認したのか
です。
例えば購入申請で、
品名：PC
数量：1台
金額：150,000円
として課長が承認したとします。
その後、申請者が自由に、
数量：10台
金額：1,500,000円
へ変更できると問題になります。
承認履歴には「課長承認」と残っていても、課長が150万円を承認したことになってしまうからです。
そのため、
- 承認後は申請内容を編集できなくする
- 編集したら再承認させる
- 承認時点の申請内容を保存する
などの設計を検討します。
申請内容を変更したら承認をリセットする
実務では、申請後に内容を変更したいケースがあります。
例えば、
申請金額：500,000円
↓
課長承認
↓
見積変更
↓
申請金額：700,000円
となった場合です。
金額が変わったのであれば、以前の承認をそのまま有効にするのは適切でない場合があります。
そこで、
内容変更
↓
承認済み状態を解除
↓
再申請
↓
再承認
とする方法があります。
重要なのは、
どの変更なら再承認が必要か
を業務ルールとして整理することです。
例えば、
備考変更
→ 再承認不要
金額変更
→ 再承認必要
契約期間変更
→ 再承認必要
などです。
承認前後のデータをどう残す？
監査証跡を強く意識する場合、申請データの変更履歴も重要になります。
例えば、
Version 1
金額：500,000円
申請日：7月30日
↓ 差し戻し
Version 2
金額：550,000円
見積書追加
再申請日：7月31日
という形です。
さらに、
課長承認
→ Version 1
部長承認
→ Version 2
と紐づければ、
それぞれの承認者がどの申請内容を確認したのか
を追跡できます。
承認履歴は上書きしない
承認履歴を監査証跡として利用するなら、過去履歴を上書きする設計は避けます。
例えば、
承認者：佐藤
承認日：7月30日
という項目を一つだけ持ち、
再承認時に、
承認者：鈴木
承認日：7月31日
へ上書きすると、佐藤さんの承認履歴が消えてしまいます。
そのため、
承認履歴1
承認履歴2
承認履歴3
のように、処理が発生するたびに新しい履歴を追加します。
つまり、
現在状態は更新するが、履歴は追加する
という考え方です。
差し戻し履歴も残す
承認だけではなく、差し戻しも重要な監査証跡です。
例えば、
申請者：田中
↓
課長：承認
↓
部長：差し戻し
理由：見積根拠不足
↓
田中：修正
↓
再申請
という流れです。
差し戻しが記録されていなければ、
なぜ申請内容が変更されたのか
を後から説明できない可能性があります。
そのため、
- 差し戻した人
- 差し戻した日時
- 差し戻し先
- 理由
を記録します。
却下と差し戻しを分ける
承認フローでは、
差し戻し
と、
却下
を同じ扱いにしない方が分かりやすい場合があります。
差し戻し
内容を修正すれば再申請可能。
却下
その申請自体を認めない。
という違いです。
監査履歴としても、
REMAND
REJECT
のように別の操作として記録すると、後から判断経緯を確認しやすくなります。
代理承認をどう記録する？
承認者が、
- 出張
- 休暇
- 病欠
などで承認できない場合、代理承認を行うことがあります。
例えば、
本来の承認者：部長A
代理承認者：部長B
というケースです。
この場合、
部長Bが承認した
だけを記録すると、
なぜ承認ルートと違う人が承認しているのか
が分かりません。
そこで、
- 本来の承認者
- 実際の承認者
- 代理承認であること
- 代理権限の有効期間
- 必要に応じて代理理由
などを記録します。
承認権限の変更履歴も重要
例えば、
7月1日時点
課長：佐藤
8月1日時点
課長：鈴木
という人事異動があったとします。
9月に7月の申請を確認したとき、
現在の組織情報だけを見ると、
なぜ佐藤さんが承認しているのか
分からなくなる場合があります。
そのため監査証跡では、
承認した時点でその人に承認権限があったのか
を確認できるようにすることが重要です。
方法としては、
- ロール変更履歴を残す
- 組織変更履歴を残す
- 承認時点の役職・権限を履歴に保存する
などがあります。
承認履歴と権限履歴を組み合わせる
例えば、
2026/07/30
承認者：佐藤
役職：営業部課長
操作：承認
という履歴を残します。
さらに権限変更履歴として、
2026/08/01
佐藤：営業部課長 → 営業部担当
と残っていれば、
7月30日時点では適切な権限を持っていた
ことを確認できます。
監査では、現在の権限だけではなく、処理時点の権限が重要になる場合があります。
承認者本人を正しく特定する
承認履歴の信頼性を高めるには、
誰が承認したのか
を正しく特定できる必要があります。
そのため、
営業部共通アカウント
のような共用IDは、承認処理では避けた方がよいでしょう。
例えば、
営業部
パスワード共有
↓
誰かが承認
という状態では、実際の操作者を特定できません。
基本的には、
- 個人ごとのアカウント
- 適切な認証
- 必要な権限管理
を組み合わせます。
高リスクな承認では再認証も検討する
重要度の高い操作では、
ログイン済みだからそのまま承認
ではなく、
承認直前に再認証
を求めるケースもあります。
例えば、
- 高額支払い
- 権限変更
- 重要契約
- 特に重要な申請
などです。
パスワード再入力や多要素認証などを利用する方法があります。
すべての承認で必要なわけではありませんが、リスクに応じて検討します。
承認履歴を監査証跡として残す7ステップ
STEP1｜対象となる承認業務を整理する
まず何を承認するのか整理します。
例えば、
- 経費申請
- 購買申請
- 稟議
- 契約
- 休暇申請
- 文書公開
などです。
STEP2｜承認ルートを整理する
例えば、
申請者
↓
課長
↓
部長
↓
役員
というルートです。
条件分岐がある場合も整理します。
STEP3｜残すべき操作を決める
例えば、
- 申請
- 承認
- 差し戻し
- 却下
- 取消
- 再申請
- 代理承認
などです。
STEP4｜履歴項目を決める
基本は、
- 誰が
- いつ
- どの申請に
- 何をしたか
です。
必要に応じて、
- コメント
- 承認ステップ
- 代理承認
- 操作時の役職
- 申請バージョン
などを追加します。
STEP5｜申請変更時のルールを決める
例えば、
承認後の金額変更
→ 再承認
備考だけ変更
→ 再承認不要
などです。
ここを曖昧にすると、承認履歴と実際の申請内容が一致しなくなる可能性があります。
STEP6｜履歴の変更・削除権限を決める
監査証跡であれば、通常ユーザーが過去履歴を書き換えられないようにします。
管理者であっても簡単に変更できない設計を検討します。
STEP7｜保存・検索方法を決める
監査時に、
- 申請番号
- 期間
- 申請者
- 承認者
- 操作
などで検索できるようにすると確認しやすくなります。
【コピペ用】承認履歴・監査証跡設計シート
対象業務
申請種類：
申請者：
承認者：
最終承認者：
承認ルート
第1承認：
第2承認：
第3承認：
条件分岐：
記録する操作
申請：
承認：
差し戻し：
却下：
再申請：
取消：
代理承認：
基本履歴
申請ID：
ユーザーID：
ユーザー名：
操作日時：
操作種類：
承認ステップ：
コメント：
申請内容
申請バージョン：
変更前：
変更後：
添付ファイル：
承認者情報
所属部署：
役職：
ロール：
代理承認：
本来の承認者：
変更ルール
承認後編集：
再承認条件：
申請取消：
監査
履歴閲覧者：
履歴出力：
保存期間：
削除権限：
改ざん防止：
承認履歴を一般ユーザーが編集できないようにする
例えば申請者が、
差し戻し履歴が邪魔だから削除する
ことができてしまうと、監査証跡として利用しにくくなります。
そのため承認履歴は、
業務操作によって自動的に作られ、通常は後から編集しない
設計が基本です。
例えば、
承認ボタン押下
↓
申請ステータス変更
＋
承認履歴追加
を同じ処理として行います。
承認者が、
「履歴を登録する」
という操作を別途行う必要はありません。
承認履歴と操作ログは分けるべき？
承認履歴と一般的な操作ログは、役割が少し異なります。
承認履歴
業務上の判断を確認するもの。
例えば、
誰が承認したか
誰が差し戻したか
です。
操作ログ
システム上で行われた操作全般を確認するもの。
例えば、
ログイン
データ変更
CSV出力
権限変更
などです。
重要な承認処理では、
承認履歴
＋
操作ログ
の両方を残す方法があります。
例えば承認履歴は業務担当者から見やすくし、詳細なシステムログは管理者・監査担当者向けにする方法です。
承認履歴の保存期間はどう決める？
承認履歴を何年間保存するかは、対象業務によって異なります。
例えば、
- 契約
- 経費
- 購買
- 人事
- 品質管理
などでは、それぞれ求められる保存期間が異なる可能性があります。
そのため、
- 法令
- 契約
- 社内規程
- 監査要件
- 業務上の必要期間
などを確認して決めます。
システム側だけで一律に、
「1年間」
などと決めないことが重要です。
承認履歴を検索できるようにする
履歴を保存していても、
数百万件のログからSQLで探さなければならない
という状態では、監査対応に時間がかかります。
必要に応じて、
- 申請番号
- 申請者
- 承認者
- 日付
- 操作
- ステータス
などから検索できる管理画面を用意します。
例えば、
承認履歴
申請番号：APP-000125
7/30 09:10 田中 申請
7/30 11:25 佐藤 承認
7/30 15:40 鈴木 差し戻し
7/31 09:05 田中 再申請
7/31 10:30 佐藤 承認
7/31 13:15 鈴木 承認
という時系列表示にすると、経緯を把握しやすくなります。
添付ファイルの差し替えにも注意する
申請には、
- 見積書
- 契約書
- 証憑
- 参考資料
などのファイルを添付することがあります。
ここで、
承認後に添付ファイルだけ差し替え可能
になっていると、承認者が確認した資料と現在表示されている資料が異なる可能性があります。
そのため、
- 承認後は添付ファイルを変更不可
- 変更したら再承認
- ファイルのバージョンを保存
などを検討します。
本文データだけではなく、承認判断に利用した添付資料も証跡の一部として考えることが重要です。
承認ルートの変更にも履歴を残す
例えば当初、
課長
↓
部長
だった承認ルートが、
課長
↓
部長
↓
役員
へ変更されたとします。
過去申請を現在の承認ルートで表示すると、
なぜ昔の申請には役員承認がないのか
分からなくなることがあります。
そのため、申請時点の承認ルートを保存する方法があります。
つまり、
現在の承認ルート
だけでなく、
その申請に適用された承認ルート
を履歴として残します。
監査証跡では「現在のマスタ」に依存しすぎない
承認者の部署・役職、承認ルート、申請区分などを現在のマスタから毎回取得すると、組織変更後に過去データの意味が変わる可能性があります。
例えば現在のユーザーマスタでは、
佐藤：一般社員
でも、承認時点では、
佐藤：課長
だったかもしれません。
そのため重要な情報は、承認時点のスナップショットとして保持する方法も検討します。
承認履歴の改ざん防止を考える
監査証跡は、
記録内容が後から都合よく変更されていない
と説明できることも重要です。
例えば、
- 一般ユーザーは履歴更新不可
- 履歴削除機能を設けない
- 管理者操作も別ログへ記録
- バックアップを取る
- 重要なログを別の保管先へ転送する
などを検討します。
必要なレベルはシステムの重要度によって異なります。
承認履歴設計でよくある失敗
失敗1｜最終承認者だけ保存する
途中の承認・差し戻し・再申請を確認できません。
処理ごとに履歴を追加します。
失敗2｜承認後も申請内容を自由に編集できる
承認者が確認した内容と現在の内容が一致しなくなります。
変更ルールと再承認条件を決めます。
失敗3｜差し戻し理由を保存しない
なぜ申請内容が変わったのか分かりにくくなります。
コメントを履歴として残します。
失敗4｜代理承認を普通の承認として記録する
本来の承認者と実際の操作者が分からなくなります。
代理承認として明示します。
失敗5｜現在の役職だけ参照する
異動後に、当時なぜその人が承認できたのか説明できない場合があります。
処理時点の権限情報を考慮します。
失敗6｜添付ファイルだけ後から変更できる
承認時に確認した資料と現在の資料が一致しなくなります。
ファイルの版管理も検討します。
失敗7｜管理者なら履歴を自由に削除できる
監査証跡の信頼性が低下します。
履歴管理権限を慎重に設計します。
失敗8｜履歴はあるが検索できない
監査のたびにエンジニアがデータ抽出する必要があります。
必要な検索・出力方法を事前に考えます。
承認履歴・監査証跡に関するよくある質問
承認履歴には何を残せばよいですか？
基本的には、
- 対象申請
- 操作者
- 操作日時
- 承認・差し戻しなどの処理
- 承認ステップ
を記録します。
必要に応じて、コメント、代理承認情報、申請バージョン、処理時点の役職なども残します。
承認後に申請内容を変更してもよいですか？
業務ルールによります。
ただし、承認判断に影響する内容を変更する場合は、以前の承認を無効にして再承認させる方法が考えられます。
承認履歴は削除できますか？
監査証跡として利用する場合は、通常ユーザーが自由に削除できない設計を検討します。
必要な保存期間や削除ルールは業務・監査要件などに合わせて決めます。
代理承認も履歴に残した方がよいですか？
後から承認経緯を確認する必要がある場合は残した方がよいでしょう。
本来の承認者と代理承認者の両方を記録すると追跡しやすくなります。
添付ファイルも版管理した方がよいですか？
承認判断に添付資料が使われる場合は検討する価値があります。
承認後にファイルが差し替わると、何を確認して承認したのか分からなくなるためです。
承認履歴と監査ログは同じですか？
重なる部分はありますが、目的が異なる場合があります。
承認履歴は業務上の判断経緯、監査ログはより広いシステム操作を記録するものとして分けることがあります。
hiro-dev-labでは承認履歴・監査証跡の設計から相談できます
hiro-dev-labでは、Webシステムの開発だけでなく、承認業務をどの粒度で履歴として残すべきか整理する段階から相談できます。
例えば、
- 現在の申請・承認業務の整理
- 承認フローの可視化
- 承認・差し戻し・却下の整理
- 承認履歴の保存項目
- 申請内容の版管理
- 再承認条件の設計
- 代理承認
- 承認者・権限履歴
- 添付ファイルの版管理
- 操作ログ・監査ログ
- 履歴検索画面
- 要求整理
- 業務要件・機能要件整理
- Webシステム設計・開発
などです。
例えば、
誰がいつ承認したか後から確認したい
承認後に申請内容が変わらないようにしたい
差し戻し・再申請も含めて履歴を残したい
監査を見据えた承認ワークフローを作りたい
という場合でも、
承認業務 → 判断ポイント → 残すべき履歴 → 変更ルール → 監査証跡
の順番で整理できます。
まとめ｜承認履歴は「誰が承認したか」だけでなく「何を承認したか」まで追えるようにする
承認履歴を監査証跡として残す場合、
「承認者と承認日時を保存する」
だけでは不十分なケースがあります。
まず、
- 誰が申請したのか
- 誰が承認したのか
- いつ処理したのか
- 承認・差し戻し・却下のどれなのか
- その時点の申請内容は何だったのか
- 途中で何が変更されたのか
- その人に当時承認権限があったのか
を後から確認できるようにします。
特に重要なのは、
「誰が承認したか」と「何を承認したか」をセットで残すこと
です。
例えば、
50万円の申請を承認
↓
承認後に100万円へ変更
できる状態では、承認履歴の意味が変わってしまいます。
そのため、
申請内容
＋
申請バージョン
＋
承認者
＋
承認日時
＋
処理内容
を紐づけます。
また、
差し戻し
↓
内容修正
↓
再申請
↓
再承認
という過程も削除せず履歴として残すことで、判断の経緯を追跡できます。
「承認済みの記録はあるが、何を承認したのか分からない」
「差し戻しや再申請まで追えるようにしたい」
「監査に耐えられる承認フローを設計したい」
という場合は、まず現在の申請業務について「後から誰に何を説明できる必要があるか」を整理するところから始めてみてください。